1. Field
The present disclosure relates to a technique or device to allow hardware related drivers to present a centralized configuration program and, more particularly, to a technique or device to allow hardware related drivers to present configuration information to a centralized user interface manager.
2. Background Information
Typically, the operation of a computer or processing system (hereafter, “computer”) may be divided into two stages, pre-boot and runtime. The pre-boot process or phase often comprises starting or resetting a computer. When first turned on (cold boot) or reset/reboot (warm boot), a computer executes the firmware that loads and starts the computer's more complicated operating system and prepares it for use. Thus, the computer can be said to pull itself up by its own bootstraps. The runtime process or phase often occurs after the pre-boot phase and includes the execution of an operating system and other user applications. The runtime phase is typically the phase that users interact with the computer. Typically the runtime phase is where the operating system (OS) has taken primary control of the system and, for the most part, the system firmware has released control of the system. Thus, the computer can be said to being running application programs.
Typically, during pre-boot, the computer is first powered on and has very limited capabilities because the volatile memory contains random data and no operating system is running. To begin the pre-boot phase, the processor is often reset to a known state and instructions found at a pre-defined location are executed. Traditionally, this pre-defined location is mapped to a non-volatile memory or firmware referred to as a Basic Input/Output System (BIOS). The BIOS often includes several low-level procedures to control the initialization of the hardware components that comprise the computer. Traditionally, each hardware component is associated with an individual driver that may have allowed the hardware device to be configured during the pre-boot phase.
FIG. 1 is a flowchart illustrating an embodiment of the traditional pre-boot phase. After a system reset 105, various hardware drivers 110, 120, & 130 may be executed. Normally, each driver that allows for user configuration is required to provide its own keystroke polling mechanism to detect the selection of a hot key. In this context, a hot key is a keystroke, such as, for example, “F2,” that launches or provides access to a hardware configuration program. Block 112 illustrates that each driver has to provide an individual mechanism to poll the keyboard. Block 114 illustrates that if any key is pressed, the driver has to determine if the proper hotkey was selected, blocks 116 & 117. If not, the driver continues to poll the keyboard until a timer expires, block 119. If the hotkey was pressed, the driver has to provide its own configuration options, user interface and program to store any selected setting, block 118. Each driver is usually required to perform some combination of blocks 112 through 119 before the operating system was allowed to boot, block 190.
This solution is less than optimal because drivers currently do not share code and a separate polling mechanism and configuration program is typically written, tested, and distributed for each driver. This consumes memory storage on the system and engineering resources. For example, an add-in card must carry a non-volatile memory, such as, for example, a flash memory, to accommodate the add-in card's own driver resources. Furthermore, the drivers are difficult to localize for international use, because the user interface programs must be recompiled and tested for each locale. In addition, the solution is less then optimal for the user, who must remember a number of hotkeys and which drivers the hotkeys are associated. Furthermore, each driver provides its own configuration program and user interface. This increases the potential for user confusion and frustration.